sensors: move baro aggregation to new sensors/vehicle_air_data #14096
Conversation
dagar
force-pushed
the
pr-vehicle_air_data
branch
4 times, most recently
from
6746e87
to
e16d3c8
Compare
|
I'll need to free up some more flash before we can consider bringing this in. |
dagar
force-pushed
the
pr-vehicle_air_data
branch
from
e16d3c8
to
14e2b81
Compare
dagar
changed the title
dagar
force-pushed
the
pr-vehicle_air_data
branch
from
14e2b81
to
86794cf
Compare
dagar
force-pushed
the
pr-vehicle_air_data
branch
from
86794cf
to
b806e9e
Compare
Tested on PixRacer V4Indoor Flight Test Procedure Notes Log https://review.px4.io/plot_app?log=16564b9b-1bea-41a3-9f5b-411f7a21d17b Tested on CUAV nano V5Indoor Flight Test Procedure Notes Log https://review.px4.io/plot_app?log=bb4a6782-2699-4f7e-a604-8e03fb0d6727 |
|
Tested on Pixhawk4 v5 f-450 Procedure Notes Log |
Tested on NXP FMUK66 v3Indoor Flight Test
|
|
Hitting the fmu-v2 flash limit again. |
dagar
changed the title
dagar
force-pushed
the
pr-vehicle_air_data
branch
from
5b54c4c
to
6f49af0
Compare
dagar
changed the title
| * @category system | ||
| * @group Sensor Calibration | ||
| */ | ||
| PARAM_DEFINE_INT32(CAL_BARO_PRIME, 0); |
There was a problem hiding this comment.
I guess this was never used, right?
There was a problem hiding this comment.
Right. We can resurrect easily enough someday if needed.
| } | ||
|
|
||
| // reschedule timeout | ||
| ScheduleDelayed(100_ms); |
There was a problem hiding this comment.
Wouldn't you move perf_end above the scheduling?
There was a problem hiding this comment.
It depends what we're trying to measure, but at the moment it's just a rough metric to get an idea of how much time we spend in each WorkItem (relative comparisons, changes over time, etc). The ScheduleDelayed() call is simply adding an entry in a list.
| if (uorb_index > 0) { | ||
| /* the first always exists, but for each further sensor, add a new validator */ | ||
| if (!_voter.add_new_validator()) { | ||
| PX4_ERR("failed to add validator for sensor_baro:%i", uorb_index); |
There was a problem hiding this comment.
What happens if this failed?
There was a problem hiding this comment.
Pushing in new data later would fail silently. In general we don't handle OOM gracefully all over the system, and I'm not sure if we ever will.
For the data validator in particular it probably makes sense to move this back PX4/Firmware side and not have most of the dynamic allocations in the first place. I'd like to get to the point where we effectively don't have any memory allocations past initial startup.
| } | ||
|
|
||
| // check for the current best sensor | ||
| int best_index = 0; |
There was a problem hiding this comment.
Should you initialize it at -1 or is 0 safe?
There was a problem hiding this comment.
Zero is safe (defaulting to the first baro instance).
|
Merge conflict with #14344 resolved. |
|
@PX4/testflights could you please do another round of flight testing here? No special requirements. |
dagar
force-pushed
the
pr-vehicle_air_data
branch
from
951d737
to
0128c26
Compare
Tested on NXP FMUK66 v3Indoor Flight Test
|
Tested on PixRacer V4Indoor Flight Test Procedure Notes Log https://review.px4.io/plot_app?log=28325e14-8eaf-4a8b-83e2-d522f817e52e Tested on CUAV nano V5Indoor Flight Test Procedure Notes Log https://review.px4.io/plot_app?log=0ce04d81-0146-4c55-9f6f-ee9c260fc944 |
dagar
force-pushed
the
pr-vehicle_air_data
branch
from
0128c26
to
1b4fb74
Compare
Continuing to carve up the long running sensors task into smaller WorkItems. This PR collects the barometer voted sensors update and handles it in a new WorkItem (managed within sensors for simplicity) that's synchronized with the primary barometer.
The
vehicle_air_datamessage has been updated with the device_id of the current primary and a timestamp_sample field has been added to get away from the overloaded use.